Swift设计模式 (iOS) (Yourtion) 23

创建型 (Creational)：单例模式 (Singleton) 结构型 (Structural)：MVC、装饰者模式 (Decorator)、适配器模式 (Adapter)、外观模式 (Facade) 行为型 (Behavioral)：观察者模式 (Observer)、备忘录模式 (Memento)

在不用继承的情况下，给已存在的类、结构体或者枚举类添加一些新的功能。最重要的一点是，你可以在你没有访问权限的情况下扩展已有类。

在 objc 的委托模式里，一个类可以通过协议来声明可选或者必须的方法

看起来似乎继承然后重写必须的方法来的更简单一点。但是考虑一下这个问题：继承的结果必定是一个独立的类，如果你想让某个对象成为多个对象的委托，那么子类这招就行不通了。

你可以把这些方法直接加在类声明里面，也可以放在扩展里，编译器不会去管数据源到底在哪里，只要能找到对应的方法就可以了。而我们之所以这样做，是为了方便其他人阅读。

了让这个视图可以复用，显示内容的工作都只能交给另一个对象来完成：它的委托。这个横滑页面应该声明一些方法让它的委托去实现，就像是  UITableView  的  UITableViewDelegate 

避免循环引用的问题，委托是  weak  类型。如果委托是  strong  类型的，当前对象持有了委托的强引用，委托又持有了当前对象的强引用，这样谁都无法释放就会导致内存泄露。

外观模式把使用和背后的实现逻辑成功解耦，同时也降低了外部代码对内部工作的依赖程度。如果底层的类发生了改变，外观的接口并不需要做修改。

便是外观模式的强大之处：如果外部文件想要添加一个新的专辑，它不会也不用去了解内部的实现逻辑是怎么样的。

注意：当你设计外观的时候，请务必牢记：使用者随时可能直接访问你的隐藏类。永远不要假设使用者会遵循你当初的设计做事。

装饰者模式可以动态的给指定的类添加一些行为和职责，而不用对原代码进行任何修改。当你需要使用子类的时候，不妨考虑一下装饰者模式，可以在原始类上面封装一层

        delegate.horizontalScrollerClickedViewAtIndex(self, index: index)

    if let initialView = delegate.initialViewIndex?(self) {

在当前  view  添加到其他  view  里的时候就会自动调用  didMoveToSuperview  方法，这样可以在正确的时间重新加载数据。

如果协议里的方法过多，可以考虑把它分解成几个更小的协议。 UITableViewDelegate  和  UITableViewDataSource  就是很好的例子，它们都是  UITableView  的协议。

 AlbumView  不应该直接和  LibraryAPI  交互，我们不应该把视图的逻辑和业务逻辑混在一起。

同样，  LibraryAPI  也不应该知道  AlbumView  这个类。

如果  AlbumView  要展示封面， LibraryAPI  需要告诉  AlbumView  图片下载完成。

苹果通过委托实现了适配器模式。委托相信大家都不陌生。举个例子，如果一个类遵循了  NSCoying  的协议，那么它一定要实现  copy  方法

设计模式针对软件设计中的常见问题，提供了一些可复用的解决方案，开发者可以通过这些模板写出易于理解且能够复用的代码

为了将代码更好的分离和重用。理想状态下，视图层应当和模型层完全分离。如果视图层不依赖任何模型层的具体实现，那么就可以很容易的被其他模型复用，用来展示不同的数据

单例模式确保每个指定的类只存在一个实例对象，并且可以全局访问那个实例

Swift 中  static  的变量是延时加载的，意味着  Instance  直到需要的时候才会被创建。

类是可以重写父类方法的，但是在扩展里不可以。扩展里的方法和属性不能和原始类里的方法和属性冲突。

适配器把自己封装起来然后暴露统一的接口给其他类，这样即使其他类的接口各不相同，也能相安无事，一起工作。

备忘录模式捕捉并且具象化一个对象的内在状态。换句话说，它把你的对象存在了某个地方，然后在以后的某个时间再把它恢复出来，而不会打破它本身的封装性，私有数据依旧是私有数据